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(FEC) to improve transmission reliability for data packets 
transmitted over packettzed data networks, such as voice 
packets transmitted over an Internet Protocol (IP) network is 
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algorithmn. The amount of error correction transmitted may 
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FORWARD ERROR CORRECTION (FEQ mission latency of 120 ms, as shown in FIG. 4, a lost packet 

FOR PACKETIZED DATA NETWORKS can be recovered before the packet is sent to the decom- 
pression hardware. In reality, the retransmission latencies 

This application is related to U.S. patent application Ser. are much greater than 120 ms, and this approach thus 

No. 09/693,782, entitled "SYSTEM AND METHOD FOR 5 becomes unacceptable. 

FRAME PACKING", filed Oct. 19, 2000, assigned to the Alternatively, each packet may be transmitted two or three 

assignee of the present application, and herein incorporated times, but this is an inefficient use of bandwidth. Thus, it 

by reference. would be desirable to have an improved error correction 

technique that could be used with VoIP systems, without 

BACKGROUND OF THE INVENTION 10 introducing large latencies and without significantly increas- 

1. Field of the Invention m S the ****** bandwidth. 

The present invention relates generally to the field of SUMMARY OF THE INVENTION 
packetized data transmission, and more particularly, to a 

system and method for forward error correction (FEC) for 15 In 8 eneral > ^ P resent invention is a system and method 
packetized data networks, such as a Voice-over-IP (VoIP) for uslQ g forward error correction (FEC) to improve trans- 
network mission reliability for data packets transmitted on a pack- 
- ~ . 4 . - A . * . j * ^ etized data network, such as an Internet Protocol (EP) 

2. Description of the Related Art netWQrk packets error ^ m transrnitted ^ 

Atypical communications network 10 is shown in FIG. 1. rately from corresponding voice packets. The error packets 

Individual computers 12, 14, 16, 18, 20 are connected via a 20 are transmitted a predetermined number of packets before 

network interface 30, 32, 34 to a network, such as the me voice packets, to increase the probability that either the 

Internet 40. The network 10 forwards and routes data sent voice packet or error packet ^ 5e received . ^ error 

from a source computer to a destination computer. packets are preferably created using a Reed-Solomon algo- 

Increasingly, such networks are also used to transmit voice rithm ^ a p proac h greatly reduces the amount of error 

signals, as well as data. In fact, digital telephones 50 may be 25 data ^ needs fo be transmitted> ^out substantially 

connected directly to the network 10, as shown in the Figure. increasing latency. 

However, since such networks were originally designed to n , . . , - 

. # A . i • i *u Additionally, the present invention may be further 

transmit data, and not necessarily m real-time, there are . a u J • n ^ *• #u * * 

U1 ' * * j 4 -44- • enhanced by dynamically adapting the amount of error 

many problems associated with transmitting voice conver- J_ . - . . J , r b « „ 

r u . . & , n correction that is sent based upon the reliability of a 

sations between two parties. 30 , A . _ iL . <- . . <. 

r network connection. In another embodiment, voice frames 

In packetized voice communication systems (e.g. Voice- md error fr^s fr om different conversations are packed at 

over-IP (VoIP), frame relay, or ATM), voice data is digitized a ^ interval to mcrease transmission efficiency, 
and lossily compressed into frames. Each frame represents 

the voice data for a small unit of time, typically 30 milli- BRIEF DESCRIPTION OF THE DRAWINGS 

seconds. Frames are then transported over the network from 35 -u. .„ , , , , , 4| _ 

, * r 4 , , The present invention will be readily understood by the 

a source to a destination, where the frames are then decom- c „ . r A , A . . 4 . . . A . .v 7 iL 

, rollowing detailed description in conjunction with the 

accompanying drawings, wherein like reference numerals 

In a Voice-over-IP (VoIP) network, each frame of voice designate like structural elements, and in which: 

data is typically encapsulated in one datagram. Hie Internet ^ mm&& Voiceover-IP network; 

Protocol (IP) imposes a minimum of 20 bytes of header, J * 

containing such information as the destination EP address. FIG * 2 ^strates a typical EP voice packet; 

The User Datagram Protocol (UDP), typically used for voice FIG- 3 is a diagram of a prior art receiving queue buffer; 

transport applications, adds another six bytes of header FIG. 4 illustrates the operation of a prior art receiving 

information. A voice frame encoded with, for example, the 45 queue buffer with packet retransmission; 

Lucent 9600 codec is 18 bytes long. (FIG. 2). FIG. 5 illustrates the operation of forward error correction 

It is the responsibility of the underlying network protocols (FEC); 

to ensure that the packets are received at the receiving end. FIG. 6 is a diagram of a typical Reed-Solomon codeword; 

Occasionally, however, packets may be lost or corrupted. In FIG. 7 is a diagram of a systematic RS(255,249) encoder; 

a protocol such as TCP running over EP if a packet is 50 FIG. 8 is a diagram of a general Reed-Solomon decoder; 

missing, it is the responsibility of the TCP layer to ask for „ TO n . ,7 

retransmission of the packet, thus ensuring data integrity. u FIG " 9 » a <ha 8f am dl f tralm S rae ™* * 

However, in a VoIP network, the compressed voice packets ^ ueue ^ accordin g to the P^ent invention; 

are time critical, and if a packet is lost there is not time to FIG ' 10 13 a °f transmission "queue pairs" 

request a retransmission of the packet. This may result in the 5S instructed according to the present invention; 

voice sounding "broken-up." FIG. U is a diagram of the operation of the present 

One common method to overcome this problem is to use invention; 

a buffer which stores a certain number of packets in a queue. FIG - 12 is a block diagram of a network interface incor- 

If a packet is missing, its retransmission can be requested porating the present invention; and 

and the packet received before the packets are decom- 60 FIG. 13 is a table showing ratios of Ecc window size, 

pressed. Packets can then be rearranged to ensure that they latency and bandwidth to compensate for a specific reliabil- 

are in the correct order. However, this produces unaccept- ity measure, 
ably long latencies as a result of the extra retransmission 

time and buffer delay. For example, in FIG. 3, the total DETAILED DESCRIPTION OF THE 

latency for the receive queue is 150 ms. For this method to 65 INVENTION 

work, the queue length needs to be sufficiently long to The following description is provided to enable any 

account for the retransmission latency. Assuming a retrans- person skilled in the art to make and use the invention and 
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sets forth the best modes contemplated by the inventor for row — limited by the bandwidth of the network. The present 

carrying out the invention. Various modifications, however, invention is designed to be able to adjust the above settings 

will remain readily apparent to those skilled in the art, since to account for more or less packet loss, 

the basic principles of the present invention have been i n further detail, the present invention employs a type of 

defined herein specifically to provide a system and method 5 Forward Error Correction (FEC) right at the packet level, 

for forward error correction (FEC) for packetized data This enables the reconstruction of whole packets instead of 

networks. Any and all such modifications, equivalents and single bit errors, which may occur at lower levels. Consider 

alternatives are intended to fall within the spirit and scope of the following assumptions: 

the present invention. 1. AU packets received are 100% correct with regard to 

In order to overcome transmission errors and packet loss, 10 data integrity. 

many systems use forward error correction (FEC). In 2. It is possible for packets not arrive at all (loss). 

general, FEC schemes transmit extra data which can be used 3 ft [s - b]e a Ret ^ kte 

at the receiving end to re-create any corrupted or lost . . A . * 1 

1 * rrr^u u r j , m rf™* * * 4. It is possible packets will arrive m an incorrect order 

packets. FEC has been applied to CD-ROMs to compensate , . K , r .... r * * *>\ 

% . . j j • ♦ j j k (may be viewed as a combination of 2 & 3). 

for scratches, and used in satellite and deep-space 15 v J t t ' 

transmissions, since the broadcast is in only one direction 5 - Du P licate packets are possible. 

(i.e. the receiver is incapable of asking for retransmission). The present invention reliably compensates for the above 

See, for example, Error Coding Cookbook: Practical C/C++ anomalies, resulting in clear and consistent voice signals, 

Routines and Recipes for Error Detection and Correction, with respect to a reasonable amount of packet loss. 

by C. Britton Rorabaugh, herein incorporated by reference. 20 Basics 

Many of these systems use the Reed-Solomon algorithm, 

which is primarily designed to take an arbitrary stream of FEC can be viewed as an advanced form of checksums, 

data and restore any corrupted section therein, with the Aset mathematical (polynomials) equations are applied to 

appropriate amount of error correction contained in the input data resulting in another set of data. The output data is 

stream. In order for the algorithm to recover data that has 25 called Error Correcting Code data (ECC data). Both sets of 

been corrupted or lost in an arbitrary location, the algorithm data ™ ^ transmitted. Upon reception, the data is 

must include enough error correction to compensate for the checked for integrity using the ECC data and the known 

fact that some error correction may not be received at the polynomials, resulting in another piece of data indicating 

receiving end as well (i.e. the algorithm needs to be able to exactly where and how the received data is incorrect and 

account for the fact that both data and error correction may 30 how t0 correct it. Note that the checking algorithm can 

be lost). As a result, applying Reed-Solomon in some cases detect discrepancies in the ECC data itself, even if it was 

can actually double the amount of data that is transmitted. corrupted. This process is illustrated graphically in FIG. 5. 

In packetized data transmission systems, the data loss is In general, the set of mathematical algorithms and equa- 
not a random length, i.e. a fixed number of packets are either „ 110115 used t0 calculate the ECC data is called "Reed- 
lost or corrupted. In other words, the data stream is not Solomon", and is well known in the art, but for background, 
interrupted at some random location for a random interval, ^ now be described below, 
but the interruption is much more predictable. Since the Reec j Solomon Codes 
actual data transmission is handled at lower layers (routers, 

etc.), the only time that a transmission will lose data is if the ^ Reed Solomon codes are a subset of BCH codes and are 

router does not have enough bandwidth or enough processor linear block codes. A Reed-Solomon code is specified as 

time to forward an entire packet. So, from a sender's point RS(nJc) with s-bit symbols. This means that the encoder 

of view, an error correction technique only needs to be able ^es k data symbols of s bits each and adds parity symbols 

to correct a packet in its entirety (not a partial packet). It also t0 make an n symbol codeword. There are n-k parity 

follows from this reasoning that the error correction data . symbols of s bits each. A Reed-Solomon decoder can correct 

should not be transmitted in the same packet as the voice 4 up to t symbols that contain errors in a codeword, where 

data. 2t-n-k. In reality, a Reed-Solomon decoder can correct up 

Note that while the present invention will be described !° 2t s y^°J s . if * e location of the errors are already 

herein specifically with reference to a Voice-over-IP ^own, which is an important feature utilized in the present 

network, the present invention may be advantageously 50 m P lementatl0n - 

applied to any network that utilizes packets to transmit FIG - 6 illustrates a typical Reed-Solomon codeword 

frames of data, in order to reduce the amount of error (known as a Systematic code because the data is left 

correction data that needs to be transmitted. unchanged and the parity symbols are appended). 

The present invention utilizes the fact that if one knows EXAMPLE 1 

the type ofdata loss ahead of time (i.e. discrete packet loss), 55 

then the amount of overhead and amount of error correction 0nc P^ 31 Reed-Solomon code is RS(255,223) having 

associated with the Reed-Solomon algorithm can be 8 " blt Each codeword contains 255 code word 

reduced. According to the present invention, for each packet of wmch 223 b V tes m data and 32 ^ arc P™*- 

of voice data that is transmitted, error correction data is For this code: 

generated and transmitted in pieces over a predetermined 60 n=255, k=223, s=8, 2t=32, t=16 

number of packets prior to the voice packet itself. At the The decoder can correct any 16-symbol errors in the code 

receiving end, what generally arrives is several error word: i.e. errors in up to 16 bytes anywhere in the codeword 

packets, and then a voice packet. In the present invention, can be automatically corrected. 

since an error correction packets are separate from the voice Given a symbol size s, the maximum codeword length (n) 

packets, this helps ensure that one or the other will be 65 for a Reed-Solomon code is: 

received. Also, additional error correction data can be gen- n=2s-l . For example, the maximum length of a code with 

erated to account for multiple packets getting lost in a 8-bit symbols (s«8) is 255 bytes. 
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Reed-Solomon codes may be shortened by (conceptually) arithmetic operations. These operations generally require 
making a number of data symbols zero at the encoder, not special hardware or software functions in order to imple- 

transmitting them, and then re-inserting them at the decoder. ment them. 

EXAMPLE 2 5 Generator Polynomial 

The RS(255,223) code described above can be shortened A Reed-Solomon codeword is generated using a special 

to (200,168). The encoder takes a block of 168 data bytes, polynomial. All valid codewords are exactly divisible by the 

and (conceptually) adds 55 zero bytes, creates a (255,223) generator polynomial. The general form of the generator 

codeword and transmits only the 168 data bytes and 32 polynomial is: 

parity bytes. 10 

Hie amount of processing "power" required to encode sCO-C^X*- 01 '* 7 ) . . . (x-a' 

and decode Reed-Solomon codes is related to the number of . # « nn i, < • , i . 

, , , - . , it* i > anc * the codeword is constructed using: 
parity symbols per codeword. A large value of t means that 

a large number of errors can be corrected but requires more 15 c{x)-g{x)-i(x) 

computational power than a small value of t. The standard 

implementation of Reed-Solomon has been described but where g(x) is the generator polynomial, i(x) is the inform a - 

since the goal of the present implementation is to recover tion block, c(x) is a valid codeword and a is referred to as 

whole packets of information, i.e. t=k, which results in a primitive element of the field, 

making 2t a large number. However, since the error locations ^ Example: Generator for RS(255,249) 
are known (i.e. a whole packet) the amount of ECC data 

actually needed according to the present invention is only k ^-.(x-a^^-a^fx-a^Cr-a^^-a^Cx-a 5 ) 

(the size of the packet itself). , , A 5 4 , 

Symbol Errors ^ Encoder Architecture 

One symbol error occurs when 1 bit in a symbol is wrong ^ 2t rit bols m a systematic Ree d-Solomon 

or when all the bits in a symbol are wrong. codeword are given by: 

EXAMPLE 3 P&HW* modg(x) 

30 

RS(255 1,223) can correct 16 symbol errors. In the worst FIG 7 shows ^ architecture for a syste matic RS(255,249) 

case 16 bit errors may occur, each in a separate symbol encoder Each of the 6 re ^ tefS R1 _ R6 holds a bo] (g ' 

(byte) so that the decoder corrects 16 bit errors In the best bits)> The arithmetic operators carry out finite field addition 

case, 16 complete byte errors occur so that the decoder or multi p lication operations on a complete symbol, 

corrects 16x8 bit errors. Reed-Solomon codes are partial- 35 

larly well suited to correcting burst errors (where a series of Decoder Architecture 
bits in the codeword are received in error). 

A general architecture for decoding Reed-Solomon codes 

Decoding is shown in FIG. 8. 

Key 

Reed-Solomon algebraic decoding procedures can correct 40 , ^ n . A , A 

j A , lt - rcxi Received codeword 

errors and erasures. An erasure occurs when the position of \ J 

an erred symbol is known (in the present implementation Syndromes 

erasures are the only occurrence). A decoder can correct up L(x) Error locator polynomial 

to t errors or up to 2t erasures. The demodulator can often Xi Error locations 

supply erasure information in a digital communication 45 yi Error magnitudes 

system, i.e. the demodulator "flags" received symbols that / v „ . 

' i;wu , . ♦ • c(x) Recovered code word 

are likely to contam errors. v 7 



V Number of errors 



When a codeword is decoded, there are three possible ™ , . , , * . „ . . , > . 

outcomes' received codeword r(x) is the onginal (transmitted) 

. T „ -* , v so codeword c(x) plus errors: 

1. It 2s+r<2t (s errors, r erasures), then the original 

transmitted code word will always be recovered. r{xyc(x)+e{x) 
OTHERWISE 

2. The decoder will detect that it cannot recover the A Reed-Solomon decoder attempts to identify the position 
original code word and indicate this fact. magnitude of up to t errors (or 2t erasures) and to correct 
OR 55 the errors or erasures. 

3. The decoder will mis-decode and recover an incorrect 

code word without any indication. The probability of each of Syndrome Calculation 

the three possibilities depends on the particular Reed- This is a similar calculation to a parity calculation. A 

Solomon code and on the number and distribution of errors. ^ Reed-Solomon codeword has 2t syndromes that depend only 

r- •* ^ i • v t- tj a ^ • on errors (not on tne transmitted code word). The syndromes 

Finite (Galois) Field Arithmetic can be calculated by substituting the 2t roots of the generator 

Reed-Solomon codes are based on a specialized area of polynomial g(x) into r(x). 

mathematics known as Galois fields, or finite fields. A finite _. 

field has the property that arithmetic operations (+,-,x,/ etc.) 65 Fjnding ^ S y mbo1 Error 

on field elements always have a result in the field. A Note that this explanation describes how to find the 

Reed -Solomon encoder or decoder needs to carry out these Symbol Error Locations in a general case. However, in the 
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present implementation, the Symbol Error Locations are 
already known and thus regenerated. In general, finding the 
Symbol Error Locations involves solving simultaneous 
equations with t unknowns. Several fast algorithms are 
available to do this. These algorithms take advantage of the 
special matrix structure of Reed-Solomon codes and greatly 
reduce the computational effort required. In general, two 
steps are involved: 

1. Find an Error Locator Polynomial 

In the preferred embodiment, this is done using the 
Berlekamp-Massey algorithm. Euclid's algorithm could be 
used and is more widely used in practice because it is easier 
to implement. However, the Berlekamp-Massey algorithm 
tends to lead to more efficient hardware and software imple- 
mentations. 

2. Find the Roots of this Polynomial 

Hiis is done using the Chien search algorithm. 

Finding the Symbol Error Values 

Similarly, this operation involves solving simultaneous 
equations with t unknowns. A widely used fast algorithm is 
the Forney algorithm. 



Transmitting the FEC Data 

As shown in FIG. 9, compressed voice packets are passed 
up from the voice hardware. ECC (Error Correcting Code) 
data is then calculated on each packet. The data is appended 
to the back of "ECC queues". Packets are then transmitted 
out the front of the queues. 

In further detail, the compressed voice packets that are 
transmitted originate from the DSP hardware. These packets 
are passed on to a transmission queue. As each packet is 
received from the hardware, ECC information is calculated 
and the ECC data is spread over the length of an attached 
ECC queue. As each packed is processed into the queue, 
packets from the other side are transmitted, either as two 
packets (ECC and data packets) or sent onto get "frame 
packed". Frame packing is described in related U.S. patent 
application Ser. No. 09/693,782 entitled "SYSTEM AND 
METHOD FOR FRAME PACKING", filed Oct. 19, 2000, 
assigned to the assignee of the present application, and 
herein incorporated by reference. 

As seen in the transmission "queue pairs" (ECC queue+ 
corresponding Data queue) in FIG. 10, ECC data is ready to 
be transmitted before some of the actual data. In this case, 
silence is transmitted for the data packets. Each "queue pair" 
in FIG. 10 represents a new packet arriving and transmitted. 
(See FIG. 9.) 

Note: 

Each data packet is transmitted after ALL corresponding 

ECC data has been transmitted, this is a fundamental in 

Forward Error Correction. 
Each piece of ECC data that is placed across the queues 

is appended to any existing ECC data. 
Transmission latency can be calculated by the size of the 

queue (in this case 5) multiplied by the sample rate, 

usually 30 ms, i.e. 5x30«150 ms 
FIGS. 9 and 10 represent one call. A List of Call queues may 
be set up for each call. 

Receiving FEC 

In general, data is received asynchronously and filtered 
back into ECC queues synchronously (same as in 
transmission). Packet sequencing is checked and corrections 
are made (if necessary) to the queue. The ECC queue is then 
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"shunted" along and the packet just received is "copied 
down" to the voice hardware, i.e. there is no latency 
involved at the receiving end. 

The receive processing will now be described in greater 
detail with reference to FIG. 11. 

1. Call data is received from a transport layer (IP, Frame 
Relay, ATM etc). This data is then pushed onto the end of a 
FIFO queue, asynchronously. The queue is used as a type of 
flow control for the synchronous data reception. 

2. The queue is then operated every time a clock Interrupt 
is received for the voice hardware. The Interrupt is taken as 
an indication that the voice hardware is waiting for another 
packet. 

3. The packet at the front of the queue is removed and 
checked whether it is an ECC or non-ECC packet. 

ECC packets are placed into an ECC queue associated 
with a particular call. The ECC packet is placed into 
whichever slot is required to match the corresponding 
data packet. For example, if the ECC packet sequence 
is 15, then there probably exists a data packet with a 
sequence of 15, which then can be matched. 

Non-ECC packets have their packet sequence checked 
relative to the back of the ECC queue, and if valid it is 
put into the back of the queue. 

4. The queue for each call is then checked to see if there 
is in fact a data packet in slot zero. 

If there is a data packet then the queue is moved or 
"shunted along" one slot. (Packets in slot 5 would get 
moved off the queue and deleted) 

If there is no packet in slot 0 then FEC is used to correct 
the missing data packet. This is done by reversing the 
process used to assemble the ECC data on the trans- 
mission side, followed by a Reed-Solomon algorithm 
decode/reconstruction. If the queue is successfully 
reconstructed, then the queue is moved or "shunted 
along" one slot. 

5. If there is a data packet in slot 1 then it is "copied 
down" to the voice hardware for further processing. 

Important points to note: 

ECC packets are placed into an ECC queue for a particu- 
lar call. An ECC packet is placed into whichever slot is 
required to match the corresponding data packet. For 
example, if the ECC packet sequence is 15, then there 
probably exists a data packet with a sequence of 15, 
which then can be matched. This operation is per- 
formed because if a data packet is late, FEC recon- 
structs that data packet (NOT the corresponding ECC 
packet as well). So when or if the data/ECC pair of 
packets does arrive, the present invention can still use 
the ECC data. 

Some voice compression CODECs have different sample 
rates — usually 30 ms, but sometimes 10 ms or 15 ms as 
well. To maintain a synchronous receiver, the voice 
hardware needs to support the different clock rate 
interrupts. Otherwise, a 30 ms clock rate is used and 
steps 3-5 are operated on 1, 2 or 3 times in one clock 
interrupt. 

As noted above, the present forward error correction 
(FEC) scheme may be combined with the frame packing 
method disclosed in the related application "SYSTEM AND 
METHOD FOR FRAME PACKING", herein incorporated 
by reference. The voice data frames at a same time interval, 
but from different conversations, can be combined into one 
packet, and the corresponding error frames combined into a 
second packet. This greatly reduces the latency associated 
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with sending the error packets, and reduces the overhead 2. The method of claim 1, wherein the separate error 

associated with prior art Reed-Solomon solutions. correction data comprises one packet. 

One of the trade-offs with doing the FEC is that since the 3. The method of claim 2, wherein the separate error 

error packets are transmitted several packets before the correction data comprises at least two packets, 

corresponding data packets, an overall latency is induced 5 4. The method of claim 3, wherein creating separate error 

(from the transmission side) in order to determine if the correction data comprises creating a forward error correction 

current voice packets arrive. However, for public IP links, as (FEC) packet utilizing a Reed-Solomon algorithm, 

illustrated by the network of FIG. 1, an additional 100 ms or 5. lie method of claim 4, wherein the separate error 

so of delay is not that noticeable. correction packet is transmitted at least one packet before 

According to prior art Reed-Solomon approaches, the 10 the data packet, 

voice data and error correction data would be placed in the 6- The method of claim 5, wherein the network is an 

same packet and the system would be useless, since if the Internet Protocol (IP) network and a data packet comprises 

packet is lost, there is no way to use the lost error data to a * oi £f data P a< ^ e ^ , . „ , . . . , , _ 

recreate the voice data. Thus, the present invention places 7 -™ e method of claim 6, wherein a receiving end buffers 

error data in a separate packet, and transmits the error packet 15 a S1 f^ nt of P a f f to determine whether an error 

within a predefined number of packets of the corresponding 1 P acket + h f been re ? ei ™ d for a responding missing or 

data packet. The present invention thus greatly reduces V01 ? P ac * et ; . „ u . . . 

overhead and thereby improves system performance. * ^ method , of clai i m 7 > wh ° rem v ° lce f™" fr ° m 

FIG. 12 is a block diagram of a network interface 70 dlfferent ^versations at a same time interval are packed 

incorporating the present invention. A network I/O module M mt ° a J» mmon packet 

71 connects the interface 70 to an external network. The ™ e method of claun 8 > wherein error frames from 

interface 70 includes a processor 72, an I/O bus 73, and a d f erent ™rsations at a same time mterval are packed 

memory 74 for processing the call packets. TT>e network mto a common packet, the packed error frames correspond- 

interface 70 has an internal operating system 75 to control m % * * e P ac ked voice frames. 

the internal operation of the interface. An internal system „ 10 * ? e method of f laim l > wherem . « ™7 int of error 

ROM 76 stores the operative control code for the interface. correction that is sent is based upon a link quality measure. 

The network interface further includes telephony hardware U * A communications system comprising: 

interface 78 for connecting to telephone equipment, and also at least 0De node and at lcast one destination node; 

includes a DSP voice compression module 79. A Forward and 

Error Correction (FEC) module 77 for provides error cor- 30 a packetized data network connection the nodes; 

rection services according to the present invention. wherein the source node sends data packets over the 

The teachings of the present invention may be further network, and sends at least one error data packet 

enhanced by dynamically adapting the amount of error corresponding to each data packet a predetermined 

correction that is sent based upon the "reliability" of a number of packets before the data packet, 

network connection. For example, a link quality manage- 35 12. The communications system of claim 11, wherein the 

ment module 80 can monitor various links available by error data packets contain forward error correction (FEC) 

sending "ping" type requests, or "echo requests" to known data. 

network nodes. When each foreign node receives an "echo 13. The communications system of claim 12, wherein the 

request", it responds to the sender by sending an "echo forward error correction (FEC) data is produced from a 

reply". The sending node notes how many responses it gets, ^ Reed-Solomon algorithm. 

and how long each takes to return. These two statistics are 14. The communications system of claim 13, wherein the 

maintained as "average loss" and "average round trip delay**. destination node buffers a sufficient number of packets to 

The "average loss" statistic is the most important measure determine whether an error packet has been received from a 

for error correction. If a link is determined to be 100% corresponding missing or corrupted data packet, 

reliable, then there is no need to transmit any error correc- 45 15. The communications system of claim 14, wherein the 

tion. If the link is only somewhat unreliable (i.e. 95%), then data packet comprises a voice data packet, 

a much smaller amount of error correction data can be 16. The communications system of claim 15, wherein 

transmitted. This in turn helps to reduce latency and band- voice frames from different conversations at a same time 

width requirements for reliable links. In practice, for any interval are packed into a common packet, 

loss less than 10%, it is more efficient to assume a 10% loss 50 17. The communications system of claim 16, wherein 

in order to reduce latency, as shown by the data table of FIG. error frames from different conversations at a same time 

13, where Ecc is "Error Checking and Correction." interval are packed into a common packet, the packed error 

Those skilled in the art will appreciate that various frames corresponding to the packed voice frames, 

adaptations and modifications of the just-described preferred 18. A method for transmitting voice data over a network 

embodiments can be configured without departing from the 5S using Internet Protocol (IP), the method comprising: 

scope and spirit of the invention. Therefore, it is to be creating a voice data packet; 

understood that, within the scope of the appended claims, creating at least one separate error correction data packet 

the invention may be practiced other than as specifically corresponding to the voice data packet, the error cor- 

described herein. rection data packet containing forward error correction 

What is claimed is: 60 (FEC) data; 

1. Amethod for transmitting data packets in a network, the transmitting the at least one separate error correction data 

method comprising: packct a predefined number of packets before the voice 

creating a data packet; data packet; 

creating separate error correction data corresponding to buffering a sufficient number of packets at a receiving end 

the data packet; and 65 to determine whether an error packet has been received 

transmitting the separate error correction data a pre- for a corresponding missing or corrupted voice packet; 

defined number of packets before the data packet. and 



09/02/2004, EAST Version: 1.4.1 



US 6,675340 Bl 



11 



using a received error packet to recreate a missing or 
corrupted voice packet. 

19. The method of claim 18, wherein the forward error 
correction (FEC) data is created using a Reed-Solomon 
algorithm. 5 

20. The method of claim 19, wherein voice frames from 
different conversations at a same time interval are packed 
into a common packet. 

21. The method of claim 20, wherein error frames from 
different conversations at a same time interval are packed 10 
into a common packet, the packed error frames correspond- 
ing to the packed voice frames. 

22. The method of claim 18, further comprising: 
determining a reliability measure of a link; and 
sending a level of error correction data based upon the 

reliability measure. 

23. A network interface comprising: 
a processor; 
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a memory connected to the processor; 

a system ROM that stored control code connected to the 

processor; and 
a Forward Error Correction Module; 
wherein the Forward Error Correction Module stores 

execution code for the processor, the execution code 

comprising: 

execution code for creating a data packet; 
execution code for creating separate correction data 

corresponding to the data packet; and 
execution code for transmitting the separate error cor- 
rection data a predefined number of packets before 
the data packet. 
24. The network interface of claim 23 further comprising 
a link quality management module. 
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